Despite the best efforts of software developers, software programs inevitably fail at one time or another. One type of failure is a crash. Crashes are frustrating to users and, in some cases, may cause the user to lose work. Another type of software program failure is a set-up failure. Set-up failures occur during installation of a program module onto a user's computer. Set-up failures may prevent certain aspects of the program module, or even the entire program module, from being installed on a user's computer.
A crash occurs while a program module is running and results in the suspension of operation of the program module. A crash may also occur if a software program or application operates to result in a state or value that causes the program to fail. For example, an unacceptable state or condition may be that X=10. Thus, any execution or operation of the software program that results in “X” being equal to “10” will cause the application to fail or crash. Each illegal execution or operation that the program performs may be said to be a “bug” that causes X=10, which results in the crash. Thus, any particular software application can have numerous operations that may cause a particular unstable state, such as X=10.
The use of asserts is a standard programming practice well known in the art. Typically, an assert is code in the software program that will alert a developer (or tester) as to whether the assumptions the software developer has made about the state of the program are not correct. For example, if a software developer believes that an operation will result in an expected condition, such as Y!=10 (Y is not equal to 10), the developer would write code into the source code file of the program to notify the developer (or a tester), of the absence of the expected state or condition. This code, known as an “assert” typically causes the display of a dialog box (“assert dialog box”) that informs the developer that the expected condition has not occurred. Thus, with the assert in place, the assert code will operate to display the assert dialog box informing the developer that the expected condition has not occurred (e.g., Y=10). Anytime an operation causes an assert to execute, the assert can be said to have been “hit” and the assert will “fire” a notification alert, such as a dialog.
As applied to diagnosing software instability such as crashes, asserts are useful in that they may be used to alert software developers and software testers of instabilities in a program. For example, if an event causes an illegal value to occur (such as X=10), an assert would “fire,” that is, it would display an assert dialog box informing the developer that the operation that was just performed resulted in and illegal or faulty condition such as X=10.
Although the firing of an assert might indicate no more than a faulty assertion that is not related to any real defect in the product, the firing of an assert may also indicate a real problem that should be fixed. In this application, a “bug” is defined as the firing of an assert that results from an operation performed by the software that results in a faulty condition. As applied in this application then, a bug occurs whenever an assert has fired.
In the current technology, the information displayed in an assert dialog box only indicates the name of the source code file and the line number on which the assert code was placed. A software tester who encounters the assert may enter this information about the bug into a table or database (resulting in the creation and maintenance of a “bug” database). Typically, the information entered usually comprises the failing condition, the name of the source code file and the line number on which the assert code was placed. Each bug may have a unique number associated with the bug.
The assert entries in the bug database can then be investigated by software developers, who can then make corrections to the product as appropriate. The bug can then be indicated as being resolved in the database (where the bug is, by definition in this application, the firing of the assert due to a faulty condition resulting).
However, a problem arises when software developers subsequently add lines of code to the source code of the computer software application being developed. Lines are added when, for example, new software versions are being developed. Each modification of the source code of the software application results in a different version, or “build” of the software application. When additional lines of code are placed into the source code, and an assert is hit, the assert will display the name of the source code file and the line number on which the assert code was placed. Although the name of the source code file will be the same from one build to the next, the line number on which the assert code was placed will change from build to build. It is often difficult to determine whether an assert occurring with two different internal builds of the program is in fact a single assert that has moved to a different line after each subsequent build.
The result is that a software developer or tester may make many duplicate entries for the same assert into the internal database containing bug information. Testers also run the risk of someone believing an assert is a duplicate when it is not, in which case the bug never gets logged in or entered, and the bug never gets fixed. Testers of software applications in particular have a much more difficult time determining or knowing whether an assert is a duplicate based on information traditionally provided because testers do not work with the actual code. All of the duplicated information for the asserts in the bug system leads to inefficiency. For example, testers may spend an inordinate amount of time attempting to locate bugs that turn out to be duplicates of previously fixed bugs, and development can spend a great deal of time tracking down what are really duplicate entries for the same assert.
Therefore, there is a need for a system and method that eliminates the entry of duplicate information for the same asserts into a database containing information about bugs associated with a particular software application or program. Such a method or system would improve the internal efficiency of a product development process. Such a system would also allow for improved stability over the lifecycle of a product to help with the development process.